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ABSTRACT 


The primary goal of this project was to develop a tailored and effective approach 
to the design and evaluation of the human-computer interface (HCI) to the 
Maintenance, Inventory and Logistics Planning (MILP) System in support of the 
Mission Operations Directorate (MOD). An additional task that was undertaken 
was to assist in the review of Ground Displays for Space Station Freedom (SSF) 
by attending the Ground Displays Interface Group (GDIG), and commenting on 
the preliminary design for these displays. 

Based upon data gathered over the 10 week period, this project has 
hypothesized that the proper HCI concept for navigating through maintenance 
databases for large space vehicles is one based upon a spatial, direct 
manipulation approach. This dialogue style can be then coupled with a traditional 
text-based DBMS, after the user has determined the general nature and location 
of the information needed. This conclusion is in contrast with the currently 
planned HCI for MILP which uses a traditional form-fill-in dialogue style for all 
data access and retrieval. 

In order to resolve this difference in HCI and dialogue styles, it is recommended 
that a comparative evaluation be performed which combines the use of both 
subjective and objective metrics to determine the optimal (performance-wise) and 
preferred approach for end users. The proposed plan has been outlined in the 
previous paragraphs and is available in its entirety in the Technical Report 
associated with this project. Further, it is suggested that several of the more 
useful features of the Maintenance Operations Management System (MOMS), 
especially those developed by the end-users, be incorporated into MILP to save 
development time and money. 
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INTRODUCTION 


The primary goal of this project was to develop a tailored and effective approach 
to the design and evaluation of the human-computer interface (HCI) to the 
Maintenance, Inventory and Logistics Planning (MILP) System in support of the 
Mission Operations Directorate (MOD). An additional task that was undertaken 
was to assist in the review of Ground Displays for Space Station Freedom (SSF) 
by attending the Ground Displays Group (GDIG), and commenting on the 
preliminary design for these displays. 

In order for the MILP and other ground and space-based systems to be effective, 
it is imperative that the HCI is convenient and easy to use so that user personnel 
can spend time solving problems, instead of grappling with the user interface. 

The MILP project was divided into several tasks as listed below, which were 
completed over a period of 10 weeks. Tasks “a" through “e” were essentially 
background tasks for production of an evaluation plan for the MILP HCI. 

(a) Review User and Task Data for MILP 

(b) Develop Scenario of Operations 

(c) Develop Storyboard of the Scenario 

(d) Conduct Storyboard/HCI Walkthrough with Users 

(e) Build Interactive Rapid Demonstration Prototype 

(f) Develop Full Comparative Evaluation Plan 


REVIEW USER AND TASK DATA FOR MILP 

The first task was to gain a sufficient understanding of the potential users of MILP 
and the tasks that they perform both with and without using automated systems. 
This was accomplished by: (1) Reading documentation about both MILP and 
similar systems, (2) observing the current MILP HCI in use, (3) observing In- 
Flight Maintenance (IFM) personnel using the Maintenance Operations 
Management System (MOMS) during a shuttle mission, and (4) by interviewing 
management personnel about their goals for the MILP system. More detailed 
information can be found in an accompanying Technical Report which is located 
in the Human-Computer Interaction Laboratory at JSC. 

The MILP system is intended to support, as its title implies, maintenance, 
inventory and logistics planning for future space missions including Space Station 
Freedom (SSF). The functional requirements for MILP have been divided into 5 
task areas which are as follows: 

1) Use and Augment Support Data and Documentation 

The purpose of this function will be to collect data about space craft and space 
craft systems and subsystems and make it available for use by support crew on 
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the ground. This function also will provide the capability to augment textual 
information with locally constructed diagrams, video, text, etc. Generally 
speaking, this data is used to help ground personnel solve problems which may 
arise onboard the space craft. This data and associated maintenance 
procedures may then be uplinked to on-orbit crews upon request. 

2) Maintain On-Orbit Replaceable Unit (ORU) Material History Data 

The purpose of the Maintain On-Orbit ORU Material History Data will be to allow 
the user to update the initial history data for each ORU to reflect current status, 
usage, and other significant life cycle events of the ORU’s. 

3) Manage Onboard Inventory 

The Manage Onboard Inventory function will provide the user with the capability 
to plan and execute inventory/stowage and resupply/return operations. The user 
will be able to: track the current status and configuration of inventory and 
stowage; use nominal procedures, crew reports, and the resupply/return manifest 
to update the current onboard inventory database; supply the location of stowage 
and the status of inventory to the program; use the program to help integrate the 
resupply/return manifest requirements and to provide to Level II for manifest 
development; develop onboard inventory databases for future increments; and 
store onboard inventory data from past increments. 

4) Compile Resupply Return Requirements 

This function will allow the user to combine resupply return requirements 
obtained from TCATS workstations. Inputs to the process will be: delta , WP, 
user, and RUPSM resupply return requirements. The system will be capable of 
receiving core systems resupply return requirements and combining them sorted 
by user query. In addition, the user will be able to transfer the combined resupply 
return requirements to the LIS for analysis. 

5) Maintain Physical Configuration 

The Maintain Physical Configuration function will allow the user to view a 
hierarchical representation of historical, current, and planned station physicaj 
configurations. Using this function, the user will be able to engage in “what-if" 
scenarios regarding station configuration. With this function, the user will be able 
to store, access and edit (if authorized) the last 2 increments and 10 future 
increments of station physical configuration data, and will be able to access an 
archive of data older than 2 increments. MILP will also maintain a time-tagged 
log of all changes to the current station physical configuration database. The 
user will also have a MILP tool which allows the hierarchical modeling of 
historical, current, and planned station physical configurations. 
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An information system currently exists to support procedure development and 
other onboard maintenance operations related to Space Shuttle missions. This 
system was also studied for applicability to the MILP project. The Maintenance 
Operations Management System (MOMS) is a computer-based system designed 
to support the development of maintenance procedures for uplink to the crew. 
The MOMS system supports some similar sub-tasks as described above in MILP 
Task 1 - Use and Augment Support Data and Documentation, however, has a 
much small scope than this task in the MILP system. MOMS does not provide 
support for the other 4 tasks required by MILP, however, it is useful to look at 
MOMS since it provides support for the only near-real-time tasking performed by 
a console operator using either MOMS or MILP. 

MOMS consists of a SUN 3/260 workstation equipped with a Parallax video 
processing board, one monochrome and one color monitor, a keyboard, and an 
optical mouse. Peripheral to the system is a suite of video equipment consisting 
of 2 optical disk storage units, a video tape player/recorder, video interface 
devices, an additional color monitor for live video signal display, and a still frame 
camera for capturing and displaying images of objects, manuals and 
photographs. Software consists of the InterLeaf publishing system, and the 
MOMS custom software for video image processing. 

MOMS includes the Interleaf desktop publishing software which allows users to 
create generic documents and incorporate text, graphics, tables and figures into 
the document. These documents are the same as any standard desktop 
publishing system can produce, however, the MOMS users (IFM) have 
developed some standard documents specifically for creating paper procedures 
and flight notes for uplink during flights, and log pages for use recording 
operator’s notes during console shifts. These documents have been put on the 
Interleaf menus for operator use. An illustration of the Interleaf screen is shown 
in Figure 1 . 

The MOMS users have also developed some customized components for use 
with the custom procedure documents. These components are items which can 
be inserted into the document at any point by placing the cursor in the document, 
and then selecting the desired insert from a menu. 

The IFM users keep a file of checklists which have been developed in response 
to various problems, and which may be recalled for use or modification at a later 
date. This file is called the Supplemental Checklist File and is stored on disk in a 
“cabinet”. This cabinet is divided into several “file drawers” alphabetically, 
according to the title of the procedure. 

Based upon observations of two MOMS users during a mission, it appeared that 
the primary usage for MOMS was and is procedure development, construction, 
and publishing. This activity mainly involves the text/publishing portion of the 
system which is displayed on the monochrome display screen. Occasionally, a 
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Figure 1 - Interleaf Screen with Open “Generic IFM” Procedure Document 


user would reference a photograph stored on one of the two video disk systems 
via the MOMS video interface, but more often the user would turn to the large 
notebooks of photographs stored in a nearby cabinet. A knowledgeable user 
stated that the search time for information from photographs in the books was 
generally faster than with the system. In addition, he stated that the resolution of 
the photos on the screen was lower than that in the books making it more difficult 
to see very small objects displayed on the screen. This is, in part, supported by 
the fact that NTSC video resolution is usually not greater than 500 horizontal 
lines, while photos are generally 2000 lines; however, the clarity of the 
photographic images displayed on the color CRT appeared quite good for many 
depicted objects. 

One of the MOMS features most relevant to MILP, the ability to capture still video 
and include it in procedures, was not often used since the technology at the time 
MOMS was built did not allow color-to-monochrome conversion at sufficent 
resolution. 

Some specific observations related to the operation of MOMS should be noted for 
input to the MILP design process: 

(1) Custom features designed by the users to facilitate procedure development 
(e.g., custom components, procedure forms (which include automatic 
renumbering of procedure steps), other user-developed forms, and special clip 
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art drawings, should be included in the basic MILP design. If Interleaf is to be 
used, these features could be directly transferred to the new system. 

(2) Image capture and translation algorithms which provide acceptable color 
image capture and color-to-grayscale translation should be employed to allow 
user to view color images, and include them in procedure documents especially 
when the final product is in black and white. 

(3) All equipment should be kept in perfect working order, and initial and periodic 
training should be given as to its proper use. This training (and the design of the 
user interface) should be oriented toward occasional users, since maintenance 
anomalies and changes to SSF configuration occur infrequently. Since SSF will 
be monitored continuously after insertion, use of MILP will be more frequent than 
the mission-oriented use of MOMS. 

(4) A method should be devised for characterizing and storing information about 
photographs which allows for the searching of image features not originally 
intended to be referenced. Users often search for pictures and locations of 
component parts, the existence of which is often not indicated in the title or the 
indices of the photograph. Search of photographs by title alone is insufficient to 
make the photo database useful to MOMS and MILP users. 

DEVELOP SCENARIO OF OPERATIONS 

The following scenario represents the actions an operator would be required to 
perform using MILP and other systems to respond to a specific Maintenance 
Contingency. This scenario contains operator and other physical and 
communication actions which are performed without the use of MILP. These 
actions are included in the scenario for completeness. 

The core upon which this scenario is built is taken from Scenario: IPS-MSN-16 
MILP: Maintenance/Contingency Support: JSC-13601; SSFP Integrated Planning 
System - Project Plan, Volume 3, Ops Concept - Appendix C. Within this core 
scenario, there are 3 possibilities, the most interesting of which is Scenario “c” - 
“Development of a new maintenance procedure and its associated activity 
definition form". Since this document contains an inter-related collection of 
scenarios which reference each other, IPS-MSN-16 serves as the base scenario, 
with portions of others included to complete the entire scenario to be 
implemented in the rapid prototype. This scenario covers the MILP Task Area 
#1, “Use and Augment Support Data and Documentation". The particular 
maintenance contingency which has been selected is based upon data collected 
from a variety of sources including: 

• Published IFM procedures (primarily GPC Replacement - Multi GPC) 

• “Ops Concept" scenarios 

• Interviews with MOMS and potential MILP users 

• Other documents 
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SCENARIO - During a payload rack installation procedure, a metal object that 
crew member was carrying accidentally slipped from the crew member’s grip. As 
the crew member was turning at a fairly high rate of speed, the object entered an 
open computer cabinet and pierced a wiring harness. The systems operator 
received an alarm at the console indicating that inter-computer communication 
had ceased. Closer inspection by the crew determined that several wires in the 
harness had been severed. The accident has occurred inside a pressurized 
module. 

The systems operator has contacted the Ops Support Officer (OSO) to discuss 
maintenance options. The unlikelihood of such an occurrence precluded the 
stocking of a replacement wiring harness. Together, the system operator, the 
OSO, and the Flight Director have decided that the maintenance action must be 
taken prior to the crew’s departure from SSF. The OSO is a MILP end-user. 

1) The OSO informs the Ops Planner that the Short Term Plan (STP) will be 
impacted (via voice). 

2) The OSO (or possibly the OSO Support Personnel or Inventory and Stowage 
Officer) using MILP, checks the inventory and determines that the spare wiring 
harness required to correct the problem is not onboard. 

3) The OSO and the systems operator explore viable maintenance options such 
as routing signals to another unit, interchanging units, or bypassing the failed 
unit. It is determined that these options are unavailable due to lack of 
redundancy and backups for this particular system. 

4) The OSO reviews the data currently in MILP to support the maintenance 
options analysis, including photographs of the rear of the computer equipment in 
place showing the location and accessibility of the damaged component. The 
OSO also finds some video of the crew replacing a computer unit on a previous 
flight. This video shows the removal and replacement of the wiring harness in 
question. 

5) For data that is not available in IPS, the OSO logs on to EDLS to browse for an 
engineering drawing showing the wiring harness in detail, and brings a copy of 
the drawing into MILP. 

5a. From an IPS workstation, an authorized EDLS user opens a window to log 
onto EDLS, browses the data, and selects products for retrieval. Alternative ly, 
the OSO may contact someone else who is custodian of engineering drawings, 
and request the drawings be retrieved. 

5b. The IPS user transmits a file transfer request from the IPS workstation via the 
FTP file transfer service as specified in the ICD. 
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5c. The transfer request is processed and the file is transferred from EDLS 
directly back to the requester’s (MILP user's) personal data area. 

6) After discussions and consultations with other Subject Matter Experts (SME’s), 
the OSO then assembles the data into 2 option related packages. For this 
scenario, these options are: a) to remove the harness and repair the severed 
wires, or b) to replace the harness with another harness using the connectors 
from the damaged harness. 

7) As the data is assembled/manipulated by the OSO, on user’s request a list of 
specific data items being analyzed at the time of request (i.e., “a snapshot") is 
automatically captured by MILP to provide a record of actions taken by the OSO. 
The records provide documentation of the analysis trail leading to the solution 
and are stored in the MILP personal data store until the maintenance action is 
completed. This data is then archived. 

8. The OSO and system operator(s) view the data in the option packages 
simultaneously to permit a complete analysis of the options. Upon completion of 
the analysis, the OSO and system operator(s) select option “a”, to repair the 
severed wires on the damaged harness, and obtain approval of the selection by 
the Flight Director. 

9. The OS informs the Systems Operations Data File (SODF) Increment 
Coordinator that a new maintenance procedure is required (via voice). 

10. The OSO builds the maintenance SOP (Using Interleaf) from the assembled 
data and coordinates with the SODF Increment Coordinator for the SOP’s import 
into PDAC. The development and validation of the flight procedure takes place 
using PDAC. The OSO has the capability to personally perform this task using 
PDAC. 

1 1 . The OSO fills out an Activity Definition Form (ADF) and contacts the Ops 
Planner (via voice) to inform him/her that the activity is ready for incorporation in 
the Short Term Plan. The OSO saves the ADF in the MILP user’s personal data 
store. 

lla. The OSO accesses the Activity Definition Interface (ADI) which provides an 
Activity Definition Form (ADF) to be filled out. 

llb. The OSO fills out the ADF. The ADI provides prompts to solicit the correct 
information for the activity definition. The OSO may enter just the basic 
information (i.e., activity name, duration, and window), and the Consolidated 
Planning System (CPS) user (the Ops Planner), through an iterative process with 
the OSO, will complete the other required information. Or the OSO may 
complete the ADF through an iterative process, making it available to the CPS 
user when complete. 


24-9 



11c. The OSO/CPS user store the resulting ADF in the shared data store. The 
OSO informs a CPS user that the ADF is stored. The OSO saves a copy of the 
ADF in his own database. 

lid. The CPS user accesses and reviews the newly-input ADF, and in an 
iterative process, consults with the OSO and other SME’s as required to insure 
the ADF(s) is as complete and accurate as possible. Data will also be obtained 
from other IPS subsystems to complete the ADF(s). 

lie. After ADF review, the CPS user imports the ADF and creates the Activity 
Definition. (The Activity Definition will require concurrence from both the OSO 
and the CPS user.) *Non-MILP Activity* 

l lf. The activity definition is verified and promoted by the CPS user to the Master 
Data Store for input into the planning process. The definition could later be 
stored as a “Master Activity Definition” in the Master Data Store if approved by 
the Ops Plan team. *Non-OSO/MILP Activity* 

llg. The CPS user uses the activity definition as building blocks in the activity 
timeline development. *Non-OSO/MILP Activity* 

12. Upon approval by the flight director, the procedure is prepared for uplink to 
the crew and the OSTP is updated and uplinked. In the Post-MTC timeframe, an 
OSTP will be developed by extracting the onboard portion of the STP and 
creating an onboard version within the CPS. *Non-OSO/MILP Activity* 

13. If the above activity crosses shifts or is interrupted for other reasons the OSO 
initiates MILP action to save the records providing documentation of the analysis 
trail so it can be retrieved for work on the next shift or at some later time. 

14. The procedure is reviewed with the crew. 

15. The OSO monitors the crew execution of the procedure and responds as 
needed to queries. If deviations from the procedure occur, the OSO annotates a 
copy of the flight procedure and logs material history and/or physical 
configuration changes. 

16. Upon completion of the maintenance action, the OSO updates the hardware’s 
material history using the Configuration and Verification Reporting System 
(CVRS), and sends a copy of the updated material history to the appropriate 
Engineering Support Center (ESC) (via FTP or Fax). 

17. The OSO updates the MILP database to document changes to the vehicle’s 
configuration as a result of the maintenance activity and transmits via TMIS a 
copy of the configuration changes to the SSFP Systems Engineering and 
Integration (SE&I) organization (or Configuration Management, TBD). 
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DEVELOP STORYBOARD OF THE SCENARIO 


The object of this task was to instantiate the operational scenario in a tangible 
HCI design which could be evaluated by project stakeholders, particularly end- 
users. The storyboards were paper-based, consisting of the types of illustrations 
shown in Figure 2. This storyboard was used to describe the high-level HCI 
concept. The complete storyboard is included in the associated Technical Report 
for this project. 

This series of storyboarded views of the MILP HCI made it possible to perform a 
critical analysis of the MILP operational scenario prior to the HCI walkthrough. 
Some significant modifications to the scenarios were made and reflected in the 
storyboard. 

First, scenario steps 5 through 5c were shown as automated in the storyboard. 
In the original scenario, the MILP user is required to open another window and 
manually log-on to another system to search a database for relevant information. 
This involves searching heterogeneous databases using different searching 
procedures and different HCI designs to accomplish a single activity. As an 
alternative, the storyboards show the dialogue design as one in which a user 
requests information about an item of interest, and is presented with a menu of 
potentially available data types. The user selects one or more of the data types 
(e.g., photos, drawings, video, procedures, etc.) and the MILP system 
automatically logs on to the system on which each data type resides and 
retrieves a list of available data items. The user then selects the items desired, 
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and MILP retrieves them from the remote system into the user’s workstation (with 
the exception of video which is handled differently). Figure 2 is an example of the 
storyboard for photographic database search results. This change does not 
preclude the possibility for the user to log on to a remote system and perform a 
manual search, however, it automates the process for all but the most complex 
searches for maintenance data items. 

CONDUCT STORYBOARD/HCI WALKTHROUGH WITH USERS 

A walkthrough of the scenario, storyboards, and the HCI concept was held on 
July 14, 1993 in the HCIL. In attendance were representatives of MOD end users 
of MOMS and MILP, the principal investigator, and another scientist from JSC 
HCIL. The purpose of the walkthrough was to validate the operational scenario, 
the storyboard, and the HCI concept for MILP. 

The most useful information was collected during the scenario walkthrough, since 
the scenario was in sufficient detail for the users to offer specific comments. 
User comments were recorded and the scenario was modified accordingly. 
Some of the more substantive modifications were: 

(1) The activity causing the accidental damage to SSF equipment was changed 
to a “payload rack installation procedure” to more closely reflect a real incident 
possibility. 

(2) The video access method was defined to reflect remote access to analog 
video tapes and equipment, instead of digitally stored video. This change 
required a modification of the HCI prior to prototype implementation. 

(3) It was determined that the Activity Definition Form (ADF) was undefined at 
this time, and there was some debate about its final composition and access. As 
a result, it was recommended that the ADF be reflected in the form of an 
Interleaf-based procedure at this time. 

(4) Checkpointing of MILP activity for archival purposes was a fuzzy concept and 
currently not well defined. This provided the opportunity to develop a new 
concept and reflect it in the prototype. 

Following the scenario walkthrough, the storyboard was reviewed. With few 
small exceptions, the HCI concept met the approval of the users. 

BUILD INTERACTIVE RAPID DEMONSTRATION PROTOTYPE 

While the storyboard can provide guidance for HCI designers, the best that can 
be expected is to transmit the concept and, in part, the “look" but not the “feel” of 
the HCI to the users. Also the storyboards are not in sufficient detail to be useful 
to evaluation the HCI in a formal sense. 
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The rapid demonstration prototype was selected as the technique used to 
complete the definition of the HCI concept and specification of the details of 
operation of the HCI for the MILP system. The rapid prototype was built primarily 
as a vehicle for expressing the trial benchmark task to be incorporated into the 
quantitative portion of the evaluation plan for the MILP HCI. 

The prototype was built on a Macintosh Quadra 950, with a high-resolution 19” 
color monitor, extended keyboard, and mouse cursor control device. The 
software used for constructing the prototype skeleton was Supercard vl.6. 
Graphics, photos, and drawings were prepared using MacDraw Pro and Adobe 
Photoshop. Video was digitized from VHS-video into Quicktime digital format for 
insertion into the prototype. With the exception of HCI detailed information, the 
rapid demonstration prototype followed the scenario and the storyboard outline. 
Those dialogue types originally portrayed in the storyboard were subsequently 
implemented in the prototype. 

The prototype is available as a stand-alone application. It is intended to be used 
to determine a benchmark for the comparative evaluation of human performance 
while users are employing alternative HCI designs to MILP. 

DEVELOP FULL COMPARATIVE EVALUATION PLAN 

The previous tasks were in preparation for the development of this comparative 
evaluation plan for the MILP HCI. Until the purpose and operational methods of 
the system are known, it is impossible to determine howto properly evaluate the 
suitability of the HCI design for the intended system mission. 

The following plan consists of 2 components; subjective and objective. The 
evaluation starts with the objective assessment of the MILP HCI, collecting data 
on a number of metrics related to user performance during maintenance 
scenarios. After each user trial, the HCI is subjectively assessed by the user, 
while completing a usability questionnaire. 

The objective component is comprised of a series of benchmark task 
comparisons across all functional areas in MILP. In order to provide a structured 
evaluation procedure, a Usability Specification Table [WHIT88] is constructed. 
An example of several possible entries in the table is shown in Table 1 . The 
measurement concept for each attribute of interest in the Usability Specification 
Table is based on a portion of a scenario like the one described in a previous 
section. Scenarios which include activities, tasks, and subtasks are required 
which are representative of user activities across all MILP Task Areas. The most 
critical type of scenario (i.e., maintenance contingency) has already been 
constructed during this project, and is ready to use in the evaluation. At least 4 
more detailed scenarios are required which cover MILP task areas: Maintain On- 
Orbit Replaceable Unit Material History Data, Manage Onboard Inventory, 
Compile Resupply Return Requirements, and Maintain Physical Configuration. 
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Table 1 - Example Entries From a MILP Usability Specification Table 


ATTRIBUTE 

MEASURING 

CONCEPT 

MEASURING 

METHOD 

WORST 

CASE 

PLANNED 

LEVEL 

BEST 

CASE 

NOW 

LEVEL 

Usability 

Maintenance 

Contingency 

Task 

Time to 
Complete the 
Scenario 

1 Hour 

30 minutes 

20 minutes 

N/A 

Usability 

Maintenance 

Contingency 

Task 

Time spent in 
errors 

15 minutes 

2 minutes 

0 minutes 

N/A 

User's 

Evaluation 

Question- 
naire Score 

Semantic 

Differential 

Score 

7 

(strongly 

negative) 

3 

(somewhat 

positive) 

1 

(strongly 

positive) 

N/A 

Preference 
Over Existing 
MILP HCI 

Question- 
naire Score 

Semantic 

Differential 

Score 

Same 

as 

Existing 


None 

Prefer 

Existing 

N/A 


As suggested by Lewis (1992) and Chin et al (1988), a subjective assessment 
instrument should be administered after the users have executed the selected 
scenarios using the HCI under evaluation. For MILP, it is felt that the usability 
questionnaire which was constructed and validated by Lewis (1992) is most 
suitable for the subjective evaluation. The questionnaire is shown in the 
complete technical report. 


CONCLUSION 

In conclusion, based upon data gathered over the 10 week period, this project 
has hypothesized that the proper HCI concept for navigating through 
maintenance databases for large space vehicles is one based upon a spatial, 
direct manipulation approach. This dialogue style can be then coupled with a 
traditional text-based DBMS, after the user has determined the general nature 
and location of the information needed. This conclusion is in contrast with the 
currently planned HCI for MILP which uses a traditional form-fill-in dialogue style 
for all data access and retrieval. 

In order to resolve this difference in HCI and dialogue styles, it is recommended 
that a comparative evaluation be performed which combines the use of both 
subjective and objective metrics to determine the optimal (performance-wise) and 
preferred approach for end users. The proposed plan has been outlined in the 
previous paragraphs and is available in its entirety in the Technical Report 
associated with this project. Further, it is suggested that several of the more 
useful features of the MOMS system, especially those developed by the end- 
users, be incorporated into MILP to save development time and money. 
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